Resolve module specifier relative to moduleFile.originalFileName #32722
Conversation
| const data = host.vfs.readFileSync("/lib/src/sub-project-2/index.d.ts", "utf8"); | ||
|
|
||
| // Prior to fixing GH31696 the import below was `import("../../lib/src/common/nonterminal")` | ||
| assert.equal(data, `declare const variable: {\n key: import("../common/nominal").Nominal<string, "MyNominal">;\n};\nexport declare function getVar(): keyof typeof variable;\nexport {};\n`); |
There was a problem hiding this comment.
Instead of this can you baseline the change. Try verifyTsbuildOutput You can pass baselineonly option
There was a problem hiding this comment.
I wanted to keep this simple. verifyTsbuildOutput seemed to do quite a bit more than was strictly necessary to test this.
There was a problem hiding this comment.
It also emits quite a bit of excess information unrelated to what I'm actually trying to verify, since it emits the entire file system diff.
There was a problem hiding this comment.
These kind of verification do not perform well when we change our emit. So baselines are better
There was a problem hiding this comment.
I've switched to baselines, but still feel that verifyTsbuildOutput was too complex for what I needed to verify.
There was a problem hiding this comment.
I disagree. With just baselineOnly option it just baselines the build. You can specify only initial build and it will baseline only that in a single file. Its like our compiler test runner that has complexities but does baseline outputs well. Having two types of baselines is just confusing and error prone later if we say want to add what happens in incremental scenario or something like that. Also you input file reside as files on disk so its easier to run normal build if needed on them.
There was a problem hiding this comment.
I looked into migrating it to verifyTsbuildOutput and I'm not convinced. The setup to use that function seems unnecessarily complicated and is undocumented. I'd much rather keep the test simple and switch to verifyTsbuildOutput if we ever need any of that added complexity. I can switch to emitting the single file patch using the same path format other tsbuild tests use, but I'd rather keep the test as focused as possible for the time being.
Prior to this fix we would resolve the module specifier relative to the file name of the referenced project's output file, rather than its input file, possibly resulting in an incorrect path.
Fixes #31696